A Software Defined Radio (SDR) is a radio whose function is defined not by its underlying hardware, but instead by its software, such that its output signal is determined by software. SDR systems are thus reconfigurable, within the limits of the actual underlying hardware capabilities, by loading new software as required by a user. FIG. 1 is a block diagram of an exemplary prior art SDR system 20. The exemplary SDR system 20 includes a means for receiving an analog or digital radio waveform at a transmission frequency (e.g., an antenna 28 and associated hardware) along with an SDR hardware component 26, an SDR software component 24, and an SDR client 22.
The SDR hardware component 26 includes a radio receiver and/or radio transmitter (which is shown for illustrative purposes only in FIG. 1 as a radio transceiver 34), as well as an analog-to-digital (A/D) converter (ADC) 30 for conversion of the radio waveform 48 (also referred to as analog baseband input) is required) to a digital baseband input signal 44 to the SDR software c component 24, and a digital to analog (D/A) converter (DAC) 32, for D/A conversion of the digital baseband output 46 from the SDR software component 24. The radio transceiver 34 is a component well understood by those of skill in the art and includes, for example, a radio frequency (RF) subsystem 38 and an intermediate frequency (IF) subsystem 36. In the receiving mode, signals received by the antenna 28 are processed by the RF subsystem 38 and IF subsystem 36: for example, the signals received at antenna 28 can be processed in a tuner (to select the desired signal, such as by filtering), a detector (to extract audio signal from the signal selected by the tuner), downconverted to the desired baseband frequency, and then sent to the ADC 30 to be converted from an analog baseband signal 48 to a digital baseband data signal 44.
In the transmit mode, the digital baseband output signal 46 from the SDR software component 24 is sent to DAC 32 for conversion to an analog baseband output signal 49, the analog baseband output signal 49 is sent the IF subsystem 36 and RF subsystem 38 of the radio transceiver 34 to the basic radio transceiver 26 for further processing, which may include upconverting the analog baseband output signal 49 to the appropriate transmission frequency, amplification, and filtering, then sent to antenna 28 for transmission.
The SDR software component 24 runs on a host, which can be a general-purpose computer system (such as described further herein in connection with FIG. 2), or hardware that has been configured by software, such as a field-programmable gate array (FPGA), embedded computing device, multiprocessor embedded systems, any equivalent computing/processing circuit. A waveform can consist of a set of SDR software components executing on general purpose processors, FPGA's, digital signal processors, etc. The host is able to handle a considerable amount of the signal processing previously done by conventional radio hardware components such as mixers, filters, amplifiers, modulators/demodulators, detectors, etc. Thus, the SDR system 20 provides a radio that can receive and transmit widely different radio protocols (sometimes referred to as waveforms) based solely on the software used.
The SDR software component 24 is in operable communication with the SDR hardware component 26 via one or more data channels. For example, in FIG. 1, the data channels include a first data channel 44 that permits reception of digital baseband input data from the ADC 30 of the SDR hardware component 26, a second data channel 46 that permits transmission of digital baseband output data from the SDR software component 24 to the SDR hardware component 26, and a control data channel 47 that permits transmission of control data from the SDR software component 24 to the SDR hardware component 26. The SDR software component 24 receives client input data 40 from an SDR client 22 and sends client output data 42 to the SDR client 22.
The digital baseband output 46 typically results from the SDR software component 24 performing a series of digital signal processing (DSP) functions necessary to prepare the client input data 40 from the SDR client 22 for transmission by the SDR hardware component 26. These functions may include: source encoding, encryption, error-correction coding, and baseband modulation, as well as the aforementioned functions performed by hardware components such as mixers, filters, amplifiers, modulators/demodulators, detectors, etc.
The SDR software component 24 of FIG. 1, as noted above, as well as the SDR client 22, each can be implemented using a known computing system such as a general purpose computer. FIG. 2 provides an illustration giving an overview of an exemplary computing system 50 usable with at least some embodiments of the invention. Note that systems and methods in accordance with the invention can be implemented using any type of computer system running any one or more types of operating systems. Exemplary types of computer systems on which at least some embodiments of the invention can be embodied include any system or device having a processor (or equivalent processing functionality) installed or embedded, including but not limited to a desktop computer, personal computer (PC), laptop computer, notebook computer, tablet computer, handheld computer, netbook, personal digital device (including but not limited to personal digital assistant (PDA), mobile communications device (including but not limited to radio, conventional telephone, mobile/cellular telephone, smart phone, music playing device, electronic reading device) server, workstation, and interconnected group of computers, as well as any other type of device having a microprocessor installed or embedded thereto, such as a field-programmable gate array (FPGA).
Referring now to FIG. 2, the computer system 50 includes a central processor 1, associated memory 2 for storing programs and/or data, an input/output controller 3, a disk controller 4, a network interface 5, a display device 7, one or more input devices 8, a fixed or hard disk drive unit 9, a removal storage device/drive (optional) 13, optionally a backup storage device (e.g., a tape drive unit) (not shown) and a data bus 6 coupling these components to allow communication therebetween.
The central processor 1 can be any type of microprocessor, such as a PENTIUM-family processor, made by Intel of Santa Clara, Calif. The display device 7 can be any type of display, such as a liquid crystal display (LCD), plasma display, cathode ray tube display (CRT), light emitting diode (LED), and the like, capable of displaying, in whole or in part, any desired information. The input device 8 can be any type of device capable of providing the desired inputs, such as keyboards, numeric keypads, touch screens, pointing devices, switches, styluses, and light pens. The network interface 5 can be any type of a device, card, adapter, or connector that provides the computer system 50 with network access to a computer or other device, such as a printer. For example, the network interface 5 can enables the computer system 50 to connect to a computer network such as the Internet. Other computer accessories well-known to those of skill in the art (e.g., microphones, cameras, speakers, biometric access-control devices such as fingerprint scanners, etc.), although not illustrated in the block diagram of FIG. 2, can of course be included as part of the computer system 50.
SDR is advantageous, flexible, efficient, and economical for users, because the SDR can evolve to meet changing or new standards by replacing software. In addition, use of SDR improves interoperability, because groups that each use SDR devices based on incompatible standards can communicate with each other by loading each group's SDR device with software that enables the two incompatible SDRs to communicate. SDR can be advantageous in military applications, and the United States Department of Defense (DoD), through its, Joint Tactical Radio System (JTRS) Joint Program Execute Office (JPEO) in San Diego, Calif., now requires that all radios delivered to any of the armed forces adhere to a so-called “Software Communications Architecture” (SCA) specification for SDR, which specification is hereby incorporated by reference in its entirety. Goals of the SCA standard include allowing all military branches to cooperate, reduce cost, increase interoperability, and provide the ability to upgrade and/or extend such SDRs developed in accordance with the SCA, from either or both of the software and hardware sides of the radio.
Several versions of the SCA specification have been developed, At the time of this writing the latest specification prepared by the STRS JPEO is SCA 2.2.2 dated 15 May 2006, the entirely of which is hereby incorporated by reference, including all of its appendices, including Appendix A (Glossary)), Appendix B (Application Environment Profile (AEP)), Appendix C (Interface Definition Language (IDL)), Appendix D (Domain Profile), Appendix D (Common Properties) Attachment, Appendix D (Common Properties) Readme Attachment. In addition, as of this writing, a new proposed SCA specification, tentatively referred to as SCA NEXT, was introduced in December 2010, Both SCA 2.2.2 and SCA NEXT, including all Appendices, are hereby incorporated by reference.
FIG. 3A is an illustrative block diagram of a prior art SCA architecture 10 (developed in accordance with SCA 2.2), which architecture illustrates the general structure of its software architecture. FIG. 3B is a prior art block diagram 11 showing the core framework (CF) layer 16 interface definition language (IDL) relationships of the prior art architecture of FIG. 3A. The prior art systems of FIGS. 3A and 3B are described briefly below and in greater detail in the SCA 2.2.2 specification itself. The elements in and operation of FIGS. 3A and 3B, along with a detailed description of a related prior art embedded distributed XML parser, are further described in commonly-assigned U.S. Pat. No. 7,367,020 (“the '020 patent”), entitled “Executable Radio Software System and Method,” which is herein incorporated by reference in its entirety.
As illustrated in FIGS. 3A and 3B, software used in at least some SCA architectures/systems 10 is organized into three layers: a processor environment layer (including operating system 12), a middleware layer 14, and a so-called “core framework” (CF) layer 16 (also referred to as a component framework layer), which includes a CF layer IDL 16a and CF layer services and applications 16b. This layer structure helps to isolate the waveform applications from the radio hardware. The processor environment layer and the middleware layer are generally commercially available off-the-shelf products. The CF layer 16, however, which is defined to be an open means to promote plug-and-play software interoperability, has been developed by a number of different suppliers, including but not limited to Raytheon Corporation of Waltham, Mass., ITT Industries of Clifton N.J., BAE Systems of the United Kingdom; Boeing Corporation of Chicago, Ill.; PrismTech of Woburn, Mass.; Communications Resource Center (CRCO) of Ottawa, Ontario Canada, and Selex Communications of Italy, as well as universities such as the Virginia Polytechnic Institute. An exemplary prior art CF layer 16 implementation is application independent, but also can be platform dependent.
The CF layer 16 also is the essential set of open application interfaces and services that provide an abstraction of the underlying Commercial Off-The-Shelf (COTS) software and hardware. Portability is achieved by implementing this same set of CF layer 16 application program interfaces on every platform. One purpose of the CF layer 16 is to deploy (load and execute) a distributed application in a controlled and secured manner. At startup, the CF layer 16 reads information in the Domain Profile (described further below) and attempts to deploy a given application to the platform, in accordance with relationships defined in the Domain Profile. Although the Domain Profile is not depicted in this figure, it is well understood by those skilled in the art and familiar with the SCA; further as those of skill in the art are aware, XML parsing of the domain profile inherently is one of the services that the CF layer 16 uses. The CF layer 16 is able to download a component (e.g., a software component) to a device, couple components together to enable them to communicate, stop and start components, handle errors, and perform other management tasks for the components. As illustrated in FIG. 3B, the CF layer 16 includes a CF Interface Definition Language (IDL) 16a and CF layer services and applications 16b. CF layer services 166, in one exemplary prior art embodiment, consist of a Domain Manager that implements system control, a Device Manager that loads software and manages a set of hardware devices, and core services such as Log, File Manager, and File System. The CF layer 16 also includes a domain manager that managers the software applications, applications factories, hardware devices, and device manager. Although the details of the CF layer's domain manager and service 16b are not expressly illustrated in FIG. 3B, such services are known to those of skill in the art and, furthermore, are shown and described in further detail in the aforementioned SCA 2.2.2 Specification and '020 patent, which are incorporated by reference.
The aforementioned Domain Profile includes a set of files in eXtensible Mark-up Language (XML) format. As is known in the art, XML is a set of rules for encoding documents in machine readable form. An XML parser parses an XML-encoded document so as to convert the XML-encoded document into an XML Document Object Model (DOM), which can then be manipulated (e.g., displayed in a browser), where the XML parser ensures that the document meets defined structures, validation, and constraints (which can be defined in a document type definition (DTD)). For example, the SCA defines XML DTDs for application, device, and service deployment information, all of which are used by the SCA Domain Manager, Application Factory, and Device Manager components of the SCA. FIG. 6, described further herein, depicts the set of XML DTD types.
The Domain Profile is a hierarchical collection of XML files that define the properties of all software components in the system and describes the SCA system's components and connections between components and describes various aspects of the hardware and software devices making up the SCA system, including the identity, capabilities, properties (including properties of embedded hardware devices), and interdependencies, as well as information about the external interfaces of the components and devices, their implementations, and how they are connected to form applications and platforms. An exemplary Domain Profile includes a set of descriptor files for describing the application (the Software Profile) and a set of descriptor files for describing the platform (the Device Profile).
Often the Domain Profiles can include a large amount of information (e.g., tens of thousands of lines of XML code spread over hundreds of files). At runtime, the XML Domain Profile is read to get configuration and deployment information. The parsing of these XML Domain Profile files, and the interpretation of the parsed data by the SCA CF, loads software components of the SCA and creates the connections between such software components and thus enables the radio to operate. The XML Domain Profile can be parsed by the SCA CF layer 16 each time the SCA radio is turned on or when an application is installed into the radio Domain. The result, in some instances, is the requirement of multiple distributed software components within the radio Domain to parse XML files.
One way the prior art CF layer 16 deploys the distributed application is through the use of CORBA. CORBA is the acronym for Common Object Request Broker Architecture, which is a standard defined by the Object Management Group (OMG) that enables software components written in multiple computer languages and running on multiple computers to work together as a single application or set of services. CORBA uses an interface definition language (IDL) to specify interfaces that objects will present to the outside world, and specifies a mapping from the IDL to a specific implementation language. Because of the use of the CORBA distributive middleware layer and Portable Operating System Interface (POSIX)-compatible open system environment, the CF layer 16 supported components can port with relative ease across different processors, Real Time Operating Systems (RTOSs), buses and Object Request Brokers (ORBs). Further information about CORBA can be found in the CORBA Specification, version 3.1 (January 2008), including Part 1 (CORBA Interface) and Part 2 (Interoperability), available from the Object Management Group (OMG), 109 Highland Ave, Needham, Mass. 02494. The CORBA Specification is hereby incorporated by reference in its entirety
Referring again to FIGS. 3A and 3B the middleware layer 14 typically includes CORBA. (distributive middleware layer) and Real Time Operating System (RTOS). As noted above, the prior art system of FIGS. 3A and 3B, as implemented in the '020 patent, also includes an embedded distributed XML parser that parses Domain profiles (which typically are defined in the SCA) of the applications for more efficiently installing and running the application. The CF layer 16 Domain Management subsystem is advantageously configured to invoke the XML parser only upon the installation of a new application or device.
As noted in the aforementioned and incorporated-by-reference '061 application one issue with at least some known implementations of the aforementioned SCA radio system is that the XML Document Object Model (DOM) validation parsers of the SCA generally are slow and large in code size and can require considerable General Purpose Processor (GPP) resources.
Various solutions have been proposed to provide an alternative to the way the existing XML DOM validation parsing function is provided, so as to improve speed and/or reduce the code size. Some proposed solutions involve offline XML parsing and/or various types of preparsing, which can be advantageous if the platform and device resources are known prior to the time of waveform deployment. For example, in the aforementioned and incorporated-by-reference '061 application, a proposed solution is provided that reduces code size and processing time by replacing the XML parser and XML files with a CORBA parser and CORBA descriptor files, so as to effectively eliminate the XML parser within the SCA radio system. For example, in one aspect the '412'061 application uses the CORBA CODEC mechanism to create a CORBA parser to replace the XML parser and uses CORBA descriptor files to replace the XML files, to greatly reduce the code size, improve parsing speed, and generally require fewer processing resources. In a further aspect, the '061 application provides a software architecture that includes a CORBA local parser interface; CORBA encoding for certain CORBA deployment types; pre-processor tools to convert XML into the CORBA deployment types and CORBA files; and, local parser interfaces for the SCA SAD and DMD, optional for the DCD when Device Manager when non-collocated with Domain Manager.
The aforementioned '061 application also provides a unique, advantageous preparsers tool located in the offline environment (i.e., a tool that is running on a system that is remote from the SDR system itself). For each type of descriptor (for example, Device Configuration Descriptor (DCD), Domain Manager Descriptor (DMD), and Software Assembly Descriptor (SAD)) used in the SCA, this offline preparsers tool preparses the XML files, including the XML descriptor files, using a COTS parser, then collapses the preparsed XML descriptor files into a corresponding CORBA structure (SAD, DCD, and DMD) that is encoded into a CORBA Common Data Representation (CDR) file using the CORBA CODEC factory. This resulting CDR file is provided to the SDR system (also referred to herein as the embedded environment or target environment), which uses the CORBA CODEC factory to decode the CDR file and extract from it the resultant CORBA structure descriptors (e.g., SAD, DCD, DMD).
In a further aspect of the incorporated-by-reference '061 application, three respective pre-processor tools pre-parse Device Configuration Descriptor (DCD), Software Assembly Descriptor (SAD), and Domain Manager Descriptor (DMD) XML files into respective CORBA structures, then convert these respective CORBA structures into respective CORBA encoded CDR files. Thus, for example, the SAD CORBA file contains a SAD encoded CDR CORBA structure (similarly true for DCD and DMD CORBA files). These preparsers tools parse and convert the XML files into CORBA representation using, at least in part, the CF PreParsers IDL.
In particular, the embodiments described in the '061 patent application improved on the prior art by:
(a) reducing this code size and processing time by replacing the XML parser and XML files with a CORBA parser and CORBA descriptor files, so as to effectively eliminate the XML parser within the SCA radio system;
(b) using CORBA's built in coding and decoding (CODEC) mechanisms, such CODEC mechanisms (along with other aspects of CORBA) to implement a system wherein the CORBA CODEC mechanism can be used, along with other features, to create, effectively, a CORBA parser to replace the XML parser; and
(c) providing a unique, advantageous preparsers tool located in the offline environment (i.e., a tool that is running on a system that is remote from the SDR system itself) that, for each type of descriptor (for example, Device Configuration Descriptor (DCD), Domain Manager Descriptor (DMD), and Software Assembly Descriptor (SAD)) used in the SCA, preparses the XML files, including the XML descriptor files, using a COTS parser, then collapses the preparsed XML descriptor files into a corresponding CORBA structure (SAD, DCD, and DMD) that is encoded into a CORBA Common Data Representation (CDR) file using the CORBA CODEC factory. This resulting CDR file is provided to the SDR system (also referred to herein as the embedded environment or target environment), which uses the CORBA CODEC factory to decode the CDR file and extract from it the resultant CORBA structure descriptors (e.g., SAD, DCD, DMD).
In the aforementioned '061 patent application, when the XML information is converted into CORBA property types during preparsing, the conversion is done such that the XML Properties (e.g., component instance properties for the different properties types) are converted to an appropriate core framework (CF) properties type, with correct values types and in correct precedence order, so that no further conversion is required when they are used with an SDR system. (The precedence order is well understood by those of skill in the art and is understood in connection with the rules specified in SCA version 2.2.2 section D.2.1 Software Package, D.6.1.3.3 componentinstantiation, concerning precedence order.)
As those of skill in the art will appreciate, the '061 patent application's above described inventive preparsers tools and XML properties conversion features helps to reduce code size and provide for more efficient operation of the SDR system, because these functions will no longer have to be done during run-time of the SDR system, but instead are done in an offline environment. For example, in one described embodiment of the '061 patent application, XML deployment information is captured in the following CORBA structures: Software Assembly Descriptor (SAD) structure, for an application that relates to SAD, Software Package Descriptors, (SPDs), Software Component Descriptors (SCDs), Application Deployment Descriptors (ADD), and Properties Descriptors (PRFs) SCA; DTDs; Device Configuration Descriptor (DCD) structure, for Device Manager that relates to DCD, SPDs, Device Package Descriptors (DPD), SCDs and PRFs SCA DTDs; and Domain Manager Configuration Descriptor (DMD) structure, for Domain Manager that relates to SCA, DMD, SPD, SCD, Deployment Platform Descriptor (PDD), PRFs, SCA DTDs.
These SAD, DCD, and DMD CORBA structures are defined based on the types defined by the existing core framework (CF) Parsers IDL interfaces for the SCA, which interfaces are further explained herein, in the figures and text, and further in the incorporated-by-reference computer program appendices, the incorporated-by-reference prior '720 patent, the incorporated-by-reference CORBA Specification, and in the incorporated-by-reference SCA Specification. Further, in one described embodiment of the '061 application, if an interface or interface operations are no longer needed by a given CF implementation, it is removed from the interface since the XML parsing is done offline.
In the '061 patent application, a method is described where three respective pre-processor tools pre-parse Device Configuration Descriptor (DCD), Software Assembly Descriptor (SAD), and Domain Manager Descriptor (DMD) XML files into respective CORBA structures, then convert these respective CORBA structures into respective CORBA encoded CDR files. Thus, for example, the SAD CORBA file contains a SAD encoded CDR CORBA structure (similarly true for DCD and DMD CORBA files). These preparsers tools parse and convert the XML files into CORBA representation using, at least in part, the CF PreParsers IDL. In addition, in one aspect of the '061 patent application, the CF_Parsers IDL file is modified by adding a local interface to its interface definitions, so that only client code is generated (and not skeletal server side code). Further, with this aspect, there need not be CORBA marshalling of interface operations (i.e., CORBA need not serialize objects associated with interface operations). For instances where the device manager is not co-located with the domain manager, the local interface is optional compile directive.
In another aspect of the '061 patent application, a software architecture is described as having a CORBA local parser interface; CORBA encoding for certain CORBA deployment types; pre-processor tools to convert XML into the CORBA deployment types and CORBA files; and, local parser interfaces for the SCA SAD and DMD, optional for the DCD when Device Manager when non-collocated with Domain Manager. Furthermore, when using the core framework (CF) implementation described in the '016 patent application in a system having a CF implementation (e.g., one based on one described in the aforementioned '020 patent) at least one or more of the embodiments of the invention described in the '061 patent application can be configured to have minimal impact to such an the existing CF Domain Manager, Device Manager, and Application Factory associated with the CF implementation based on the '020 patent, because the at least one or more embodiments, as described in the '061 patent application, can be configured to use substantially similar interfaces, types and operations.